home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2926 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.6 KB
  1. Path: news.connectnet.com!usenet
  2. From: jtara@connectnet.com (Jon Tara)
  3. Newsgroups: comp.graphics.algorithms,comp.lang.c++,comp.os.ms-windows.programmer.graphics,comp.os.ms-windows.programmer.multimedia,comp.os.ms-windows.programmer.win32
  4. Subject: Re: IJG JPEG Engine and Win32
  5. Date: Sat, 20 Jan 1996 16:10:33 GMT
  6. Organization: CONNECTnet Internet Network Services (service provider)
  7. Message-ID: <310110c0.44581633@news.connectnet.com>
  8. References: <4cemir$6vb@redstone.interpath.net> <TGL.96Jan3202549@netcom21.netcom.com> <TGL.96Jan5065424@netcom21.netcom.com> <4cpn1r$gm0@redstone.interpath.net> <4crai5$ear@hades.rz.uni-sb.de> <4d11tg$56q@redstone.interpath.net>
  9. NNTP-Posting-Host: jtara.connectnet.com
  10. X-Newsreader: Forte Agent .99c/16.141
  11.  
  12. fortunat@interpath.com (Jumpstile Turner) wrote:
  13.  
  14. > Incidently, malloc() and free() are measureably slower under 
  15. >Windows 95.  These generate calls to GlobalAlloc which are still in the 
  16. >Win32 API just for compatability. Under Win32 you want to use HeapAlloc 
  17. >or VirtualAlloc if you can.  
  18.  
  19. I'm not sure that using VirtualAlloc() would be such a good idea,
  20. except for large blocks. malloc() and free() grab large blocks and
  21. then divvy them up, so most of the time when you call malloc() it
  22. doesn't actually go out to the operating system and allocate anything.
  23.  
  24. Are you sure that GlobalAlloc doesn't wind up calling
  25.  
  26. >I've also been looking at sucking the JPG 
  27. >files into RAM and decoding them from ram because JPG's tend to be 
  28. >rather small while they're compressed. I'm not sure if I'll gain any 
  29. >speed benefit from doing so yet. 
  30.  
  31. The IJG library can make use of the ability to "back up" in the file -
  32. that way, it can avoid allocating some buffers in some cases. Not sure
  33. if this really gains you much.
  34.  
  35. Rather than sucking the files into RAM, though, why not just
  36. memory-map the file?
  37.  
  38. In my app, I bring the JPG in and out through a CArchive, which
  39. precludes direct access to the file (I could be serializing from/to a
  40. CSocket, for example) and backing up. This would be a case for sucking
  41. it into memory first, IF there is a significant advantage to being
  42. able to back up.
  43.  
  44. Right now, though, I'm perfectly happy with malloc() for allocation
  45. and letting the default MFC code (in CDocument) read the file for me.
  46. It seems significantly faster than Lview Pro (not sure why - I have
  47. the 32 bit version - is it not using the IJG code?) so I'm happy.
  48.  
  49.  
  50. ________________________________________________________________________
  51. jtara@live.net  A new video clip (Netscape 1.1+) of San Diego Bay every half hour:
  52.  <URL:http://live.net/sandiego/> Rated top 5% & "best 1000" by Point Communications
  53.  
  54.  
  55.